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Abstract 

Enterprises  are  increasingly  complex;  especially  those  found  in  National  Defense.  They  are 
dynamic  systems,  geographically  and  operationally  distributed,  and  faced  with  operating  with 
increased  agility  in  “always  on”  conditions  under  greater  regulatory  scrutiny  within  highly 
volatile  “market”  conditions  where  continuous  quality  improvements  are  expected.  This 
situation  requires  continuous  improvements  in  the  conduct  of  enterprise  operations,  with  a 
corresponding  increase  in  the  efficacy  of  decision  (command)  and  control  applied  to  all  facets  of 
enterprise  management.  To  address  this  challenge  we  introduce  and  engineering  model 
supporting  advances  in  both  the  concept  and  implementation  of  enterprise  command  and  control 
(EC2)  systems.  We  characterize  the  objectives  of  EC2  in  tenns  of  units  of  value  production 
(VPU)  that  function  at  the  intersection  of  enterprise  supply  and  asset  chains.  Enterprise 
governance  is  consequently  focused  on  the  continuous  optimization  of  perfonnance  of  value 
production  processes  linked  by  these  two  value  chains.  VPUs  range  in  size  and  function  from 
low  level  tactical,  to  mid-level  operational,  to  high  level  strategic  activities,  all  of  which  must 
interact  effectively  in  order  to  sustain  enterprise  viability.  This  paper  provides  a  summary  of  our 
work  in  the  application  of  our  VPU  model  to  the  EC2  requirements  of  complex  federated 
enterprise  systems. 

Key  Words:  Enterprise,  Command  and  Control,  Systems  Engineering,  Enterprise  Systems, 
Cybernetics,  Agile  Systems,  Reactive  Systems,  Real-time  Systems 

1  Enterprise  Value  Production 

Our  thesis  is  that  effective  (e.g.,  agile  and  error  free)  governance  of  large-scale  distribute,  always 
on,  real-time  enterprise1,  in  response  to  probabilistic  environmental  and  self-imposed  demands, 
requires  the  systematic  ( engineered)  application  of  an  intelligent  decision  and  control  system 
framework2.  To  improve  the  efficacy  of  management  we  are  presently  designing  advanced 
software  systems  to  assist  in  real-time  distributed  enterprise  decision  (command)  and  control 
(EC2).  Doing  so  requires  a  concise  operational  definition  of  enterprise  and  an  identification  of 
its  core  value  production  processes,  processes  that  can  benefit  from  improvements  in  automation 
and  control. 


1  The  term  “enterprise”  refers  to  an  arbitrary  but  named  unit  of  organization  whose  existence  is 
expressly  for  the  stable  production  of  a  quantifiable  measure  of  value. 

1  The  term  “framework”  refers  to  an  architectural  pattern,  the  definition  of  a  complete,  coherent 
and  self-consistent  template  for  creation  of  applications  within  a  given  domain. 
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To  maintain  its  viability3  an  enterprise  must  be  dynamically  stable4 .  Stability  requires  that  it 
offer  a  sustainable  and  competitive  value  proposition  to  the  evolving  environment  (e.g., 
“marketplace”  or  “battlespace”)  within  which  it  operates.  A  value  proposition  defines  the  ratio 
between  the  costs  to  provide  a  benefit  to  a  domain  and  the  domain’s  continuous  revaluation  (e.g., 
“clearing  price”)  for  that  benefit.  This  requires  enterprise  to  be  agile  (adaptive)  with  respect  to 
changing  domain  conditions. 

The  difference  between  fully  burdened  value  production  costs  and  domain  clearing  prices, 
measured  in  the  domain’s  economic  units,  equals  the  marginal  benefit  [profit )  realized  by  the 
enterprise  in  the  continuous  evaluation  ( execution )  its  value  propositions.  An  enterprise  is  viable 
to  the  extent  this  marginal  benefit  is  both  sustainable  and  sufficient  to  fuel  adaptation  within  its 
competitive  environment.  In  other  words, 

A  viable  enterprise  is  a  computational  object  (virtual  machine)  that  continuously 
executes  a  finite  set  of  adaptive  programs  (its  value  propositions)  whose  results 
provide  marginal  benefits  sufficient  to  1)  satisfy  its  evolving  market  requirements 
and  2)  fuel  internal  innovations  sufficient  to  maintain  homeostasis. 

Enterprise  decision  and  control  is  about  responding  to  evolving  operating  situations  through 
development  of  appropriate  responses.  Responses  define  the  continuous  improvements  to  core 
value  production  processes  required  for  maintaining  viability.  To  quantify  and  continuously 
improve  value  production,  we  need  a  model  of  a  value  production  unit  (VPU). 

1. 1  Units  of  Value  Production 

The  locus  of  enterprise  management  activity  responsible  for  production  of  a  quantifiable  measure 
of  value  is  referred  to  as  a  value  production  unit  (VPU).  A  VPU  is  an  abstract  object5  that 
participates  in  production  webs  with  other  VPUs.  As  drawn  in  Figure  1  webs  are  bound  by  value 
chains,  specifically  a  vertical  asset  chain  and  a  horizontal  supply  chain. 

A  VPU  is  uniquely  identified  by  a  relative  address  within  the  web.  In  Figure  1  VPU[k,l] 
identifies  a  value  production  process  at  the  “1th”  level  in  an  asset  chain  and  the  “kth”  position  in  a 
supply  chain.  VPU[k,l]  is  subordinate,  and  therefore  accountable  to,  VPU[k,l+l]  in  the  asset 
chain,  and  a  serwer  or  service  provider,  and  therefore  committed  to,  VPU[k+l,  1]  in  the  supply 
chain.  Fikewise,  VPU[k,l]  is  a  superior  to,  and  therefore  responsible  for,  VPU[k,l-l]  in  the  asset 
chain,  and  a  client  of,  and  therefore  dependent  on,  VPU[k-l,l]  in  the  supply  chain. 

A  VPU  may  simultaneously  participate  in  a  number  of  non-conflicting  webs.6  VPUs 
interconnect  through  four  sets  of  duplex  communications  ports,  two  each  for  the  two  value 


5  A  system  is  “viable”  to  the  extent  it  maintains  its  existence  over  time. 

4  In  natural  systems,  dynamic  stability  in  the  face  of  evolutionary  pressures  is  referred  to  as 
homeostasis. 

5  A  VPU  is  an  enterprise  virtual  machine  representing  (i.e.,  a  proxy  for)  one  or  more  real 
enterprise  activities  that  results  in  a  specific  and  quantifiable  degree  of  value  production. 

6  For  this  analysis  we  will  consider  only  single  vertical  and  horizontal  VPU  dependencies.  Issues 
of  VPU  fan-out  and  fan-in  are  treated  elsewhere. 
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chains.  Arrows  associated  with  each  port  indicate  the  direction  of  the  flow  of  increasing  value. 
The  function  of  each  port  is  summarized  in  Table  1. 


Superior 

a.  ro 


Server 


Subordinate 


Client 


Sj  — 


Figure  1  -  Value  Product  Units  (VPU) 


Table  1  -  VPU  Communications 


Value 

Chain 

Port 

ID 

Port  Name 

Port  Function 

Asset  Chain 

ai 

Assets  In 

Acceptance  and  assimilation,  according  to  a  service-level  agreement  (SLA),  of 
allocated  assets  from  superior  VPUs 

rD 

Returns  Out 

Production  of  returns  on  value  produced  by  previously  allocated  assets; 
requests  for  allocation  of  additional  assets 

a0 

Assets  Out 

Allocation,  based  on  a  SLA,  of  assets  to  subordinate  VPUs  with  expectations 
for  a  minimum  time-specific  return  of  value  for  the  allocation 

n 

Returns  In 

Acceptance  and  assimilation  of  returns  and  evaluation  of  requests  for  asset 
allocations  from  subordinate  VPUs 

Supply  Chain 

d; 

Demand  In 

Acceptance  of  demands  (orders)  for  goods  or  services  from  upstream  consumer 
(client)  VPUs 

So 

Supply  Out 

Fulfillment  of  demand  (orders)  in  the  form  of  goods  or  services  to  downstream 
consumer  (client)  VPUs 

d0 

Demand  Out 

Issuance  of  demands  (orders)  for  goods  or  services  to  upstream  producer 
(server)  VPUs 

Si 

Supply  In 

Acceptance  of  fulfilled  orders  for  goods  or  services  from  downstream  producer 
(server)  VPUs 
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This  characterization  of  value  production  identities  the  core  computational  requirement  of  a 
VPU,  and  therefore  the  principle  objective  of  decision  and  control,  as  the  simultaneous  and 
continuous  (i.e.,  real-time)  optimization  of  value  production  on  both  intersecting  value  chains. 
In  the  web  framework  this  is  both  a  local  (internal,  closed,  private)  optimization  problem 
performed  within  a  VPU,  and  a  global  (external,  open,  public)  optimization  among  neighbors 
within  the  lattice.  Governance  (EC2)  of  an  enterprise  may  therefore  be  viewed  as  the  individual 
and  federated  management  of  populations  of  interacting  VPUs. 

2  Enterprise  Command  and  Control  (EC2)  Model 

In  adaptive  systems,  coordinated  local  and  global  optimization  through  feedback  control 
mechanisms  is  a  generally  complex  activity,  even  for  relatively  simple  processes  operating  in 
static  environments.  Enterprises  and  their  embedded  value  production  processes  are  far  from 
simple,  either  individually  or  in  ensemble.  Furthermore,  they  operate  in  dynamic  environments 
where  adaptation  is  a  key  determinant  of  survival  through  sustainable  value  production. 


Figure  2  -  Enterprise  Policy  Domains  (Trees)7 


Enterprise  C2  must  therefore  serve  a  range  of  value  production  management  requirements,  from 
control  of  short-term,  highly  dynamic,  internal  tactical  activities  to  longer-term,  more  slowly 
evolving,  global  strategic  activities.  In  the  middle  of  this  spectrum  are  the  more  methodical, 
mundane  and  pragmatic  operational  activities  that  represent  the  core  of  enterprise  behavior. 


7  The  figure  represents  the  scope  of  the  US  DOD  Unified  Command  Structure  (UCS),  but  could 
equally  we  represent  the  structure  of  medium  to  large  scale  commercial  enterprise. 
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Identifying  these  activities  and  striking  a  balance  between  tactical,  operational  and  strategic 
initiatives  is  critical  to  survival. 

We  begin  to  quantify  these  behaviors  by  describing  the  nature  of  asset  chains  -  behaviors  in  the 
well-known  and  often  maligned  policy  or  accountability  hierarchy  of  enterprise.  Figure  2 
diagrams  a  six  level  enterprise  structure  .  The  figure  represents  the  US  National  Command 
Structure,  including  the  President  of  the  US  (POTUS),  the  Cabinet  and  Joint  Chiefs  of  Staff  at 
Level  5,  the  US  Joint  Forces  and  Strategic  Commands  at  Level  4,  down  to  men,  machines  and 
material  at  Level  0.  To  represent  commercial  enterprise,  the  levels  in  this  figure  could  equally 
well  be  labeled  with  business  terminology  (business  areas,  units,  production  plants,  etc), 
representing  management  domains  where  generally  accepted  accounting  practices  (GAAP)  are 
applied,  where  fiduciary  accountability  must  be  maintained  to  sustain  equity  market  viability, 
and  where  causal  relations  must  be  maintained  in  order  to  sustain  regulatory  and  legal  viability. 

2.1  EC2  Policy  Framework 

The  top  level  node  in  Figure  2  defines  the  root  of  a  policy  domain  tree,  where  each  subordinate 
node  represents,  in  a  recursive  fashion,  the  root  of  a  subordinate  or  embedded  policy  domain. 
Policy  domains  define  regions  where  enterprise  decision  and  control  action  is  governed 
(constrained)  by  policies  or  doctrines  that  relate  to  domain-specific  value  propositions9 .  Policies 
express  ethical,  political,  legal,  financial,  temporal  or  other  conditions  under  which  VPUs  must 
operate,  individually  and  in  ensemble. 

Each  node  in  a  policy  domain  tree  represents  one  or  more  VPUs,  with  their  vertical  links 
defining  an  asset  chain  and  their  horizontal  links  defining  supply  chains.  Figure  3  diagrams 
value  chains  as  might  exist  within  and  between  two  hypothetical  allied  military  enterprises, 
identified  here  as  “A”  and  “B.”  They  have  defined  a  high-level  inter-domain  supply  chain 
agreement  (“coalition”)  denoted  by  the  dashed  line  linking  their  respective  Level  5  policy 
domains.  Within  military  A  there  is  an  internal  Level  3  supply  chain  between  its  B2  and  B3 
policy  domains.  There  are  intra-coalition  Level  1  and  Level  3  supply  chains  between  the  A1  and 
B3. 

The  normal  and  routine  functioning  of  enterprise  consists  of  decision  and  control  occurring 
throughout  its  policy  domain  hierarchy,  often  with  only  loose  social  concepts  of  EC2.  This 
essentially  ad  hoc  approach  to  management  is  a  principle  source  of  tactical,  operational  and 
strategic  errors  and  inefficiency,  resulting  in  slow  response  (loss  of  agility)  and  lost  productivity. 


Six  is  somewhat  arbitrary  number,  but  serves  to  emphasize  a  (typical)  management  structure  of 
medium  to  large  scale  enterprise. 

9  A  value  proposition  is  a  predicate  specification  of  the  general  form: 

if  <situation>  and  <response>  then  <expected  result> 
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Figure  3  -  Inter-Enterprise  Supply  Chains 


At  its  simplest, 

Enterprise  command  and  control  is  the  exercise  of  authority  and  direction.  In 
general,  EC2  is  the  real-time  exercise  of  policy-constrained  authority  and 
direction,  guided  by  a  manager ’s  intent  (command)  and  accomplished  through  an 
adaptable,  decentralized,  and  cross-organizational  arrangement  of  capabilities 
(i.e.,  personnel,  services,  communications  and  equipment)  that  are  inter¬ 
connected  and  that  operate  through  a  common  shared  information  infrastructure 
(control). 

While  intuitive  and  useful,  this  definition  is  far  from  prescriptive  on  the  act  of  “doing  C2.”  A 
more  operational  definition  would  necessarily  include  description  of  the  activity  or  process  of 


Copyright  ©  Jay  Bayne,  All  Rights  Reserved 
Filename:  CCRTS  Papervl.doc 


Page  7  of 23 


3/21/2004 
Version:  1.0 


2004  Command  and  Control  Research  &  Technology  Symposium 

The  Power  of  Information  Age  Concepts  and  Technologies 

C2.  Figure  4  presents  a  classical10  C2  process  with  its  generalized  services.  The  figure 
identifies,  beginning  at  the  bottom,  a  value  production  process  under  control  (PUC).  The  process 
control  loop  begins  with  one  or  more  measurements  of  the  status  (i.e.,  actual  or  inferred 
behavior)  of  the  process* 11.  These  measurements  collectively  feed  the  activity  of  sensory 
perception,  qualified  by  policy-based  value  judgments  and  historical  trend  information  stored  in 
a  process  model  (i.e.,  knowledge  base).  Together  these  activities  constitute  the  continuous  act  of 
maintaining  a  degree  of  situational  awareness.  Once  appropriately  aware  of  the  current  situation 
the  activities  of  behavior  generation  (planning  and  model  update)  and  execution  (resource 
management  and  final  control)  complete  the  control  loop.  This  cycle  may  operate  continuously, 
be  periodically  invoked,  or  be  aperiodic,  running  asynchronously  only  when  measurements 
generate  perceptions  that  exceed  some  specific  threshold  and  trigger  a  C2  reaction.  The  inner 
loop  of  the  C2  process,  when  automated,  provides  a  degree  of  self-regulatory  or  autonomic 
control.  The  outer  loop,  generally  in  the  heads  and  hands  of  human  beings,  provides  various 
degrees  of  adaptive  supervisory  control. 


Intelligent  Control 

Adaptivo 

Control 

Loop 


Measurement 


PUC 


PUC:  Process  Under  Control 

Figure  4  -  The  Process  of  EC2 


The  model  is  nested,  with  each  node  in  an  accountability  hierarchy  executing  this  C2  process  (in 
an  appropriate  form)  and  treating  subordinate  VPU  nodes  as  their  respective  “processes  under 
control.”  Similarly,  each  policy  domain  is  embedded  in  a  higher-level  domain.  Figure  5 
expresses  the  important  point  that  EC2  is  a  process  that  happens  throughout  the  policy  domain 
hierarchy,  concurrently,  within  each  VPU.  Control  derives  not  from  a  centralized  function,  but 
rather  from  the  collective  behavior  of  federations  of  collaborative  C2  processes  -  distributed 
control,  operating  under  a  cascading  set  of  policies.  Coherence  of  behavior  is  achieved  through 
1)  nested  policy  domains  and  2)  collaboration  along  value  chains  among  cooperating  VPUs. 

10  The  figure  is  a  classic  model  of  feedback  control  in  adaptive  systems,  and  at  the  heart  of  the 
science  of  cybernetics  -  automation  and  control  in  complex  dynamic  systems. 

11  Measurements  may  be  made  synchronously  (sampled)  or  asynchronously  (event  driven). 
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Ideally,  in  supporting  scale  economics  and  the  desire  for  validated  (quality)  and  reusable  process 
steps,  the  EC2  process  is  implemented  at  each  node  using  common  underlying  methods.  Figure 
5  expresses  this  ideal  situation  by  implying  that  tactical  C2  at  the  base  of  the  policy  tree  and 
strategic  C2  at  the  top  are  both  carried  out,  simultaneously,  using  the  same  C2  process  model. 
Each  node  in  a  policy  tree  is  a  virtual  machine  that  executes  the  C2  process  on  behalf  of  its  value 
propositions. 


Figure  5  -  Pervasive,  Adaptive  and  “Always-On”  EC2 


Figure  2,  Figure  4  and  Figure  5  taken  together  express  two  fundamental  challenges  of  EC2  in 
distributed  systems:  simultaneously  managing  intra-domain  and  inter-domain  value  production 
among  cooperating  VPUs  (i.e.,  communities  of  interest,  COI).  This  is  the  all  too  familiar 
societal,  commercial  and  sovereign  governmental  dilemma  of  managing  the  competing  interests 
of  the  private  (internal,  personal)  and  public  (external,  allied)  aspects  of  value  production.  The 
collaborative  management  of  public  (i.e.,  federated)  domain  value  production  requires  a  policy 
commons  among  cooperating  entities.  Such  a  commons  provides  the  basis  of  service  level 
agreements  (SLA)  that  govern  value  chain  contracts  among  the  federated  VPUs. 

2.2  Unified  Enterprise  C2  Structure 

Within  a  policy  domain  hierarchy  the  process  of  adaptive  C2  must  be  governed  in  order  to 
manage  inheritance  of  value  propositions  and  their  associated  policy  specifications.  As  noted, 
managing  value  production  within  and  across  enterprise  policy  domains  requires  existence  of  1) 
one  or  more  value  production  processes,  2)  well  defined  and  scalable  machinery  for 
implementing  consistent  C2  measurement  and  control  processes  (Figure  4),  and  3)  formal  user 
interfaces  for  engaging  responsible  human  management  actors  engaged  in  both  private  and 
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public  value  production.  Taken  together,  these  three  elements  comprise  our  Enterprise  Control 
Model  (ECM),  shown  in  Figure  6. 


EC2  Environment  Actors 


EC2  Support  Services 


Policies 

Assets 

Scenarios 

Audit 


Situations 

COA/POA 

POR 


a 


Supervisor 


a 


Planner 

Regulator 
Operator 
Auditor 


Director  1 

h‘ 


Director  "n” 


(a) 


(b) 


(c) 


(d) 


Figure  6  -  EC2  Actor  Model 


At  the  core  of  the  C2  challenge  is  provision  of  coordinated  automation  and  control.  Enterprise 
management  is  responsible  for  materially  improving  the  efficacy  of  value  production,  especially 
in  supporting  efficient  and  reliable  collaboration  among  (i.e.,  distributed  and  federated)  human 
enterprise  actors.  Simply  stated,  EC2  is  a  management  service  within  an  enterprise.  Processes 
deliver  services  (i.e.,  execute  service  applications).  The  structure  of  C2  processes  ( actors )  is 
diagrammed  in  Figure  6c,  the  components  of  which  are  outlined  in  Table  2.  Each  component 
represents  an  echelon  “  (E)  of  control.  Governance  by  actors  requires  an  organization  in  order  to 
coordinate  the  behavior  of  the  actors  and  to  manage  the  acquisition  and  disposition  of  resources 
each  requires. 

Within  a  given  policy  domain  it  is  typical  to  find  several  governance  roles,  each  defined  by  a 
generalized  set  of  responsibilities.  Again  referring  to  Figure  6c  and  Table  2,  the  organizational 
activities  and  their  interrelationships  include:  at  echelon  5  (E5),  the  highest  level  of  authority, 
domain  management  (supervision);  at  echelon  4  (E4),  the  analysis,  planning  and  development 
functions  for  managing  adaptation;  at  echelon  3  (E3),  the  operations  directorate  for  executing 
plans  of  action,  including  its  audit  function  (E3*);  at  echelon  2  (E2),  regulatory  controls  needed 
for  coordinating  parallel  task  that  cooperate  (rendezvous)  and  access  shared  resources;  at  echelon 
1  (El),  the  task  directors  that  manage  specific  value  production  processes  and  their  interaction 


12 

The  term  “echelon”  refers  to  the  level,  rank  or  authority  of  an  entity. 
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with  value  chains  (Pn)  at  E0.  Here  “n,”  the  number  of  such  subordinate  value  production 
processes,  is  equal  to  or  greater  than  one,  and  typically  less  than  10. 


Table  2  -  Principle  Enterprise  C2  Processes 


Echelon 

Service  Name 

Enterprise  Roles  &  Responsibilities 

E5 

Supervision 

Goals,  Objectives  &  Policy  Domain  Management 

E4 

Planning 

Mission  Capability  Management 

E3 

Operations 

Program  &  Capability  Management 

E3* 

Auditing 

Program  and  Process  Performance  Assessment 

E2 

Control 

Process  (Task)  Synchronization 

El 

Command 

Process  (Task)  Management 

E0 

Process 

Value  Production  Process  (Task) 

Note:  designates  a  subordinate  role  at  a  given  echelon. 


Note  in  Figure  6c  that  the  management  organization  for  E0  VPUs  is  structured,  at  the  next  lower 
level  of  the  policy  tree,  identically  to  it’s  parent  (supervising,  containing)  VPU.  This  nested 
(recursive)  model  is  a  key  element  in  our  distributed  ESM  model,  and  is  consistent  with  the  goal 
of  designing  service-oriented  EC2  solutions  that  scale. 

The  recursive  structure  of  the  ECM  controller  model  is  diagrammed  in  Figure  7.  Notice  that  as 
we  look  deeper  into  the  organization,  at  each  successive  level  in  the  policy  domain  we  find  the 
same  management  structure.  This  facilitates  designing  and  deploying  a  common  set  of  C2 
services  that  can  be  used  throughout  the  enterprise.  Without  such  a  symmetric  and  recursive 
control  model,  each  domain  would  have  to  create  its  own  machinery  for  C2  and  force  linkages  to 
other  domains  in  a  federation. 

2.3  Enterprise  C2  Actors 

Within  complex  enterprise  systems,  each  of  the  process  control  entities  mentioned  is  managed 
(administered,  supervised,  directed,  governed,  owned)  by  a  human  actor.  These  actors  are 
diagrammed  in  Figure  6d,  and  summarized  in  Table  3,  and  are  key  elements  of  C2  services  since 
they  drive  the  C2  applications.  They  represent  the  captain  (pilot)  and  crew  of  the  enterprise 
VPU. 

The  process  model  shown  is  derived  from  cybernetics  ,  and  consists  of  familiar  management 
functions  found  in  naturally  occurring  and  man-made  systems.  For  any  given  activity  there  is  a 
superior  authority  responsible  for  its  conduct  (E5);  there  is  an  actor  responsible  for  sensing 
impending  changes  in  the  environment  containing  the  activity  and  planning  for  and  developing 
consequential  adaptations  required  to  maintain  enterprise  efficacy  (E4);  there  is  an  actor 
responsible  for  executing  planned  and  resourced  actions  (E3);  there  is  an  actor  responsible  for 
assessing  the  performance  of  currently  executing  activities  (E3*);  there  are  actors  responsible  for 
carrying  out  tasks  specified  in  the  E3  plans  (El);  and  there  are  actors  responsible  for 
coordinating  parallel  and  interdependent  tasks  (E2)  when  there  are  multiple  E1/E0  tasks.  The 
behavior  of  each  echelon  controller  (i.e.,  the  VPU  object’s  methods),  and  the  protocols  used  to 
link  them,  are  the  subject  of  an  Echelon  4  Inc.  design  document. 


13  The  term  “cybernetics”  refers  to  the  science  of  dynamic  systems,  and  the  technical  space 
where  computing,  communications  and  automatic  (feedback)  controls  intersect. 
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Figure  7  -  Recursive  EC2  Actor  Model 


Table  3  -  Principle  EC2  Actors 


Actor 

Actor  Name 

Count 

Enterprise  Actor  Roles 

E5 

Supervisor 

1 

Policy  Domain  Manager,  Policy  Management 

E4 

Planner 

2 

Mission  Capabilities  Manager,  Enterprise  Systems  Engineering 

E3 

Operator 

1 

Program  Manager,  Operations 

E3* 

Auditor 

1 

Program  and  Process  Performance  Assessment  Manager 

E2 

Controller 

N>1 

Per-process  (Task)  Synchronization  Manager 

El 

Commander 

N>1 

Per-process  (Task)  Manager 

E0 

Producer 

N>1 

Value  Production  Task 

Note:  “*”  designates  a  subordinate  role  at  a  given  echelon. 


2.3.1  Enterprise  Operating  Context 

Enterprise  is  embedded  in  and  dependent  upon  a  specific  operating  environment  or  context,  e.g., 
an  economic  marketplace,  a  military  battlespace,  a  healthcare  concern.  This  context  provides 
input  to  and  receives  output  from  the  value  production  processes  of  contained  VPUs.  As  shown 
in  Figure  6b,  the  context  is  further  partitioned  into  specific,  typically  overlapping,  regions  where 
C2  processes  are  focused.  There  exist  regions  of  the  environment  that  support  strategic  planning 
and  provide  insight  into  possible  future  situations,  identified  with  E4.  There  are  regions, 
identified  with  E3,  where  the  VPUs’  aggregate  behavior  is  focused  and  where  its  operating 
conditions  are  unfolding.  And  there  are  sub  regions  of  the  environment,  identified  with  the  El- 
E0,  where  the  individual  subordinate  VPUs  operate  in  tactical  ways  to  reach  their  targets.  This 
containment  hierarchy  corresponds  to  the  policy  domains  of  Figure  2. 

Figure  6a  shows  shared  support  services  (aka,  “information  infrastructure”)  required  for 
managing  the  conduct  of  integrated  enterprise  behavior.  The  figure  identifies  a  few  of  the  key 
grid-connected  information  systems.  They  include  repositories  for  the  enterprise’s  operating 
policies,  reusable  and  consumable  assets,  and  validated  scenarios  (aka,  defined  business 
processes).  In  addition,  the  infrastructure  supports  storage  of  past  and  present  of  situations 
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encountered,  past  and  present  plans  of  action  (POA  -  feasible  responses  to  situations),  and 
current  in-process  plans  of  record  (POR  -  resourced  and  in-process  commitments  to  current 
situations).  These  information  assets  provide  the  basis  for  coordinated  action,  discussed  below. 

2.3.2  Enterprise  C2  Application 

The  decision  and  control  application  program  executed  by  the  enterprise  echelon  controllers  is 
diagrammed  in  Figure  8,  with  its  major  components  summarized  in  Table  4.  The  application’s 
inputs  are  measures  of  the  present  state  of  its  environment  (. situations )  and  whose  outputs  are  the 
VPU’s  responses  to  these  situations  in  the  form  of  executable  plans  of  record  (POR). 


E4 

Context  Model 
Development 


Copyright  C  2004  JS  Bayne 
All  Righto  Reserved 


E4 
Situation 
Assessment 


E3 

Behavior  (POA) 
Generation 


Figure  8  -  EC2  Application  Components 


The  program  behaves  as  follows.  Situations,  in  the  form  of  periodic  measurement  subscriptions, 
asynchronous  alarms  and  events,  arising  internally  and  in  the  value  chains  are  consumed  by  A3, 
the  situation  assessment  (SA)  process.  The  process  uses  the  context  model  database  (MB),  the 
validated  scenario  database  (SB),  the  asset  database  (AB),  and  the  policy  database  (PB)  to  triage 
and  analyze  current  situations.  The  outputs  of  SA  are  scenarios  representing  potential  courses  of 
action  (COA)  that  respond  to  current  situations.  The  COA  are  subsequently  input  to  A4,  the 
behavior  generation  process  (BG).  BG  uses  MB,  SB,  AB,  and  PB  to  triage  and  prioritize  COA 
against  currently  executing  plans  in  order  to  convert  COA  into  coordinated  plans  of  action 
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(POA).  The  final  step  of  BG  is  to  assign,  when  available,  required  resources  to  POA  converting 
them  to  executable  plans  of  record  (POR). 

Figure  8  also  identifies  five  supporting  application  components.  A1  and  A2  provide  interactive 
management  of  the  model  and  scenario  databases,  respectively.  A5  and  A6  provide  interactive 
management  of  the  policy  and  asset  databases,  respectively.  And  POR  are  put  into  execution 
and  monitored  by  A7.  As  a  final  note,  the  principle  actors  introduced  in  Figure  6  are  shown  in 
relation  to  the  seven  application  components. 


Table  4  -  EC2  Application  Components  (ref:  Figure  8) 


Component 

Principle 

Actors 

Function 

Input 

Output 

At 

Model 

Management 

E4 

Enterprise  Model 
Development 

Subscription-based  real-time 
operating  situations  and  events; 
policy  constraints;  asset 
constraints;  current  situation  model 

Updated  Model  Database 
(MB) 

A2 

Scenario 

Management 

E4 

Enterprise 

Scenario 

Development 

Policy  base  updates;  asset  base 
status 

updates;  validated  scenarios; 
current  aggregate  situation  model 

Updated  Scenario  Database 
(SD) 

A3 

Situation 

Assessment 

E5,  E4 

Enterprise 

Situation 

Generation 

Current  domain  capabilities; 
prioritized  course  of  action  (COI); 
current  plans  of  record  (POR) 

Prioritized  list  of  potential 
courses  of  action  (COA) 
with  resource  requirements 
and  policy  issues;  updated 
context  situation  model 

A4 

Behavior 

Generation 

E3 

Enterprise 

Behavior 

Generation 

Prioritized  Courses  of  Action 
(COA) 

Updated  set  of  resourced 
and  prioritized  plans  of 
record  (POR) 

A5 

Policy 

Management 

E5 

Enterprise  Policy 
Management 

Current  policy  status;  current  asset 
status;  current  COA  status;  current 
POR  status;  superior’s  policy 
status 

Updated  domain  Policy 
Database  (PB) 

A6 

Asset 

Management 

E3,E4 

Enterprise  Asset 
Management 

Current  asset  status;  current  policy 
status;  current  POR  status;  unmet 
COA  requirements;  subordinates’ 
asset  status 

Updated  domain  Asset 
Database  (AB) 

A7 

Operations 

Management 

E3 

Enterprise 

Operations 

Management 

Pending  POR 

Sequenced  execution  of 

POR 

2.3.3  Collaborating  VPUs 

VPU’s  must  collaborate  in  two  dimensions,  simultaneously.  They  participate  in  their  vertical 
asset  chain  and  horizontally  in  their  supply  chain  engagements.  Policies  and  associated 
communications  protocols  differ  with  respect  to  value  chain  C2  requirements. 

We  noted  in  Section  2.1  that  policy  domains  are  defined  by  both  peer-peer  and  superior- 
subordinate  relations.  The  superior-subordinate  dimension  establishes  the  command 
accountability  structure  of  enterprise.  If  our  C2  solution  is  to  scale  effectively,  is  to  be 
economical  in  implementation,  and  is  capable  of  being  validated  for  correct  and  dependable 


Copyright  ©  Jay  Bayne,  All  Rights  Reserved 
Filename:  CCRTS  Papervl.doc 


Page  14  of  23 


3/21/2004 
Version:  1.0 


2004  Command  and  Control  Research  &  Technology  Symposium 

The  Power  of  Information  Age  Concepts  and  Technologies 

operation.  It  must  not  depend  explicitly  on  the  VPU’s  level  in  the  policy  tree  or  its  position  in  the 
supply  chain.  This  domain-neutral  requirement  limits  options  for  constructing  ad  hoc  policies 
and  mechanisms  for  collaboration  control.  Our  solution  is  based  on  the  recursive  nature  of 
containment  within  accountability  structures. 

In  Figure  9  three  VPUs  are  engaged  in  (one  of  potentially  many)  collaborations  related  to  their 
interdependent  asset  and  supply  chain  activities.  The  Asset  Chain  Director  in  VPU[k,l]  is  in 
collaboration  with  her  counterpart  in  subordinate  VPU[k,l-l].  At  the  same  time,  the  Supply 
Chain  Director  in  VPU[k,l]  is  in  collaboration  with  his  peer-level  supplier  VPU[k-l,l].  Within 
VPU[k,l]  it  is  the  responsibility  of  the  Operator  to  provide  and  coordinate  plans  (of  record)  for 
the  Asset  and  Supply  Chain  Directors  that  meet  the  objectives  of  the  Supervisor  and  her  Planner. 


Figure  9  -  Collaboration  among  EC2  Domains 


The  Asset  and  Supply  Chain  Directors  are  responsible  for  their  E0  asset  and  supply  chain  value 
production  processes,  respectively.  As  discussed,  each  of  these  E0  processes  may  contain  nested 
VPUs,  as  described  in  Figure  7.  The  nesting  may,  and  likely  will,  contain  lower  level  asset  and 
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supply  chain  relationships.  This  situation  motivates  the  design  and  development  of  generalized 
(e.g.,  scalable,  object-  and  grid-based)  EC2  services  that  can  be  deployed  at  all  levels  of  the 
enterprise. 

To  facilitate  discussion  of  the  collaboration  between  VPUs  in  Figure  9,  we  have  drawn  Figure 
10,  a  diagram  that  offers  a  shared  “whiteboard”  metaphor  on  which  situation  assessment  and 
plan  execution  can  take  place  among  the  various  actors.  The  whiteboard  represents  the  multi- 
media  environment  on  which  the  shared  activities  of  Figure  8  are  played  out  between 
cooperating  VPUs  (i.e.,  members  of  a  given  community  of  interest). 


Collaboration  “Whiteboard” 
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Figure  11  -  DOD  USSTRATCOM  Command  Center  Concept  Drawings 


Feeds 


Figure  12  -  EC2  Bridge  Concept 
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The  machinery  supporting  this  collaborative  environment  is  referred  to  as  the  “C2  Bridge.”  We 
expect  that  some  form  of  bridge  services  are  required  in  all  enterprises  that  participate  within  the 
EC2  environment.  Bridge  services  will  also  need  to  scale  from  some  lowest  common 
denominator  (LCD  -  pun  intended!)  to  sophisticated  large-scale  US  Defense  Department 
enterprise  environments,  as  in  Figure  11. 

To  support  our  model  of  EC2-guided  VPUs,  the  bridge  technical  environment  must  contain 
elements  introduced  in  Figure  6  and  Figure  8.  In  particular,  the  C2  Bridge  comprises  a  set  of 
possibly  shared  services,  as  in  an  ASP14,  that  support  collaboration  on  both  private  (intra-VPU) 
and  public  (inter- VPU)  situation  assessment  and  behavior  generation  tasks.  The  bridge  services 
are  introduced  in  block  diagram  form  in  Figure  12.  Situations  inter  the  bridge  at  the  lower  left, 
are  aggregated  and  filtered  and  entered  first  into  a  performance  measurement  process,  then  a 
historian.  Some  inputs  qualify  as  alarms  or  important  events  and  are  presented  to  the  Alann  & 
Event  processor. 

Current  and  historical  information  are  subsequently  input  to  a  display  generator  that  provides 
synoptic  views  on  shared  displays  and  actors’  workstations.  Based  on  this  input  actors  respond 
through  interaction  with  the  core  EC2  applications  (A1-A7),  as  depicted  in  Figure  8.  Actors  also 
interact  with  the  enterprise  VPU  through  a  level  selection  mechanism. 

The  bridge  enables  a  wide  range  of  control  functions  that  support  enterprise  operations.  The 
control  functions  and  their  impact  on  viability  are  the  subject  of  another  paper. 


3  Conclusions 

Our  thesis  is  that: 

Effective  (agile  and  error  free)  governance  of  large-scale  distribute,  always  on, 
real-time  enterprise  that  is  capable  of  responding  to  probabilistic  external  and 
internal  demands  requires  systematic  (engineered)  application  of  an  intelligent 
decision  and  control  system  framework. 

We  have  provided  both  a  lexicon  for  expressing  enterprise  C2  and  the  outline  for  an  operational 
framework  for  implementing  scalable,  distributed  real-time  processes  of  command  and  control. 
The  work  described  here  forms  the  basis  for  our  current  efforts  at  constructing  an  EC2 
demonstration  system,  with  special  emphasis  on  the  requirements  of  joint  command  and 
collaborative  C2. 


14  ASP:  an  Internet  service  provision  point,  a  web-based  “Application  Service  Portal” 
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□ 

EC2  Environment  Actors 


EC2  Context  Model 


Supervisor 

Planner 


Director 
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□□□  Echelon 4 Corporation  EC2  Plans  Of  ReCOfCt  (POR) 


task  { 

plan  { 

task  id; 

plan  id; 

tasktime; 

plantime; 

task  resources; 

plan  resources; 

task  policies; 

plan  policies; 

task  risk  { 

plan  risk  { 

task_risk_time; 
task  risk  resources; 

} 

taskpredecessors; 

plan_risk_time; 
plan  risk  resources; 

} 

plan_predecessors; 

task  successors; 

plan  successors; 

task  start  time; 

plan  start  time; 

task_completion_time; 

plan_completion_time; 

task  penalty  function; 

plan  penalty  function; 

task_critical_path; 

plan_critical_path; 

task_manager; 

plan_manager; 

task_init();  /*  task  resourcing  7 

plan_init();  /*  pain  resourcing  7 

task_proc();  /*  task  process  (step  list)  7 

plan_proc();  /*  plan  process  (task  list)  */ 

task  error();  /*  task  error  handler  7 

plan  error();  /*  plan  error  handler  7 

task  end();  /*  task  clean  up  on  end  7 

plan  end();  /*  plan  clean  up  on  end  7 

task  status();  /*  task  current  status  7 

plan  statusQ;  /*  plan  current  status  7 

task  etc();  /*  task  est  time  to  complete  7 

} 

plan  etc();  /*  plan  est  time  to  complete  7 

} 
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□□□  Echelon  4  Corporation  EC2  Application 


E5  E4 

Policy  Policy  Baso 

Management  Development 
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□□□  Echelon  4  Corporation 

□ 


Collaborative  EC2 
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□□□  Echelon 4 Corporation  EC2  "  Bridge” 


C2  Level  r  C2  Level 
Commentary  Alarms  &  Events 


Command 
Inputs 


Command  r  Command  Control 

Courses  of  Action  Plans  of  Action  Inputs 


Control 
Plans  of  Record 


Status  of 
Executing 
Plans  of  Record 


■ 


Command 

Policies 


Situation 

Assessment 


m 


Control 

Policies 


Behavior 

Generation 


Command 

Assets 


Control 

Assets 
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E5  Supervisory  Workstation 


E4  Analysis  &  Planning  Workstation 
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Asset  Chain  Collaboration 


□ 

□□□  Echelon  4  Corporation 

□ 


Superior-Subordinate  Command  Chain 
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□□□  Echelon 4 Corporation  Supply  Chain  Collaboration 


Peer-Peer  Command  Chain 
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□ 

□□□  Echelon  4  Corporation 
□ 


Enterprise  Performance 


Potential 

-  What  a  process  is  potentially 
capable  of  doing 

Capability 

-  What  a  process  is  “ resourced ” 
to  do 

Actuality 

-  What  a  process  is  actually 
doing 

Latency 

-  Ratio  of  Capability  to  Potential 

Productivity 

-  Ratio  of  Actuality  to  Capability 

Performance 

-  Ratio  of  Actuality  to  Potential 
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□ 

□□□  Echelon  4  Corporation 

□ 


Q&A 
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